home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / files / packet / thenet / tn212.exe / TN211-14.DOC < prev    next >
Text File  |  1993-08-09  |  5KB  |  87 lines
  1.                               TN211_14.DOC
  2.                        SYSOP REMOTE PARAMETERS (12-16)
  3.                      ***********************************
  4.  
  5.                            Parameter 12, TXDELAY
  6.                            ---------------------
  7.     Node  radio  TXD  is adjustable in 10 ms increments.     The value selected
  8. should  be  based  both  on the node's T/R capability and on the ability of the
  9. worst case  radio in the link to respond.    Factors  influencing  response and
  10. approximate times are:
  11.  
  12.    1.  2 - 20 ms to overcome receive squelch (if squelched).
  13.    2.  2 - 5 ms for switched crystal oscillators to settle.
  14.    3.  10 - 50 ms for older mechanical T/R relays to switch.
  15.    4.  5 - 10 ms for modern reed relays to switch.
  16.    5.  350 ms for PLL circuits to switch and settle.
  17.  
  18. Other than recommending users to upgrade their radios,  a LAN NodeOp has little
  19. control over user radio TXD's.    This being the case,  the suggested TXD for a
  20. LAN node is "30" (300 ms).  If certain  users experience repeated retries, than
  21. TXD  should be bumped higher, as necessary.    Radios selected for backbone use
  22. should be faster responding and TXDs can be set accordingly.
  23. (Range:  0-255)
  24.  
  25.                         Parameter 13, BROADCAST VIA PORT
  26.                         --------------------------------
  27.     Under certain networking configurations,  it's desirable to control whether
  28. the  NODES broadcast will be allowed or not, over the RS-232 and the HDLC radio
  29. ports.   A typical example would be an isolated LAN node where NODES broadcasts
  30. over the radio port would just add QRM to the channel, since there are no other
  31. nodes to receive them.   Another example would be an access node not wanting to
  32. advertise  its  presence  onto a backboned trunking system.    In this case the
  33. broadcast  would  be blocked  via the RS-232 port.   Even though broadcasts are
  34. inhibited,  it  doesn't  prevent  reception  of  broadcasts  from  other nodes.
  35. 0  =  broadcasts via NO ports, 1  =  broadcasts via HDLC  radio port only,  2 =
  36. broadcasts via RS-232 port only,  3 = broadcasts via both ports.
  37. (Range: 0-3)
  38.  
  39.                           Parameter 14, # PROPAGATE
  40.                           -------------------------
  41.  
  42.     A portion of the  node-to-node  overhead is taken up with  the inclusion of
  43. # hidden nodes in the NODES broadcasts.   In large backboned trunking networks,
  44. the # hidden nodes can contribute significantly to network clutter.   Since the
  45. status of the  # hidden nodes are  typically of interest only to local NodeOps,
  46. it  would be desirable to limit their propagation into the system.    Suggested
  47. value is "0."   0 = OFF, no propagation,  1 = ON, allowed to propagate.
  48. (Range: 0-1)
  49.  
  50.  
  51.                      Parameter 15, CONNECT COMMAND ENABLE
  52.                      ------------------------------------
  53.  
  54.     A  factor  enhancing  improved  throughput on backboned trunking systems is
  55. the  lack of collisions  due to  allowing  (in the most modern of systems) only
  56. ONE transmitter  per  link frequency.     This configuration  can be maintained
  57. simply  by disallowing  connected  users  to issue a  CONNECT  command FROM the
  58. protected node.   User  connect  attempts  will be quietly ignored.   Transport
  59. layer 4 connect  requests from adjacent nodes are not affected and are serviced
  60. in the normal way.  With exception of the special case mentioned, the suggested
  61. value is "1".    0 = CONNECT command disabled,  1 = CONNECT command enabled.
  62. (Range: 0-1)
  63.  
  64.  
  65.                    Parameter 16, DESTINATION LIST LENGTH
  66.                    -------------------------------------
  67.  
  68.    Limits  the maximum  number of nodes,  both hidden and non-hidden, that will
  69. accumulate in the ROUTING table.   This table contains an  alphabetical listing
  70. by  alias  of  distant  (destination)  nodes  picked up during neighbor node(s)
  71. broadcasts.     This is the  same listing a  user sees  in response to a  NODES
  72. command.    The term  "Destination"  implies  a user  is able to  make a single
  73. connect to any  of the nodes listed in the 'destination table'.  With each node
  74. listed,  the amount of "free buffers" within the node's memory space is reduced
  75. by 36 bytes.    Depending  upon the  number of  nodes in the table,  the node's
  76. memory  could  become  temporarily  depleted.  Should this happen, the response
  77. to  certain  commands  will be   "Node busy".     The number of free buffers is
  78. shown in parenthesis during the USERS command response.
  79.  
  80. Free  buffer depletion is not normally a problem with the typical node when the
  81. maximum  table  size  is  limited to 100.   If the  Minimum Quality for Update,
  82. parameter  1,  is  sized to  limit  the number  of  nodes  to  those  that  are
  83. "connectable",  the  NODES  table will  normally contain far fewer than the 100
  84. limit.  Suggested value is "100".
  85. (Range: 1-400)
  86.  
  87.